After the development of more than 30 years, the Ethernet technique based on Transmission Control Protocol/Internet Protocol (TCP/IP) has become a dominant local area network technique. The Ethernet technique has find applications successfully in core networks of public networks, as well as metropolitan area networks, and has penetrated into public access networks gradually. The Ethernet technique has become a de facto transport protocol standard for almost every application. Due to its simplicity, flexibility and low lost, it has gained significant advantages over some traditional techniques, such as token ring, Fiber Distributed Data Interface (FDDI) and Asynchronous Transfer Mode (ATM).
With the development of Ethernet-based Local Area Networks (LAN) and Ethernet switching technique, IP network is expected to provide services, such as end to end forwarding control, etc., in addition to the traditional services, such as email, network surfing, etc. Multi-Protocol Label Switching (MPLS) is a technique for forwarding acceleration based on a label between link layer header and network layer header, which is recently developed on the basis of IP techniques in combination with ATM techniques. MPLS is compatible with a variety of network techniques and link layer techniques, and has find broad application in the fields of Virtual Private Networking (VPN), traffic engineering, Quality of Service (QoS), etc.
Downstream Label Switch Router (LSR) is a basic component unit of an MPLS network. A network constituted by LSRs is referred to as an MPLS domain. An LSR which is located at the edge of the MPLS domain and connected with other user networks is referred to as an edge LSR, and an LSR located inside the MPLS domain is referred to as a core LSR. The core LSR may be an MPLS-supporting router, or may be an ATM-LSR upgraded from an ATM exchange or the like. A labeled packet is transmitted along a Label Switched Path (LSP) consisting of a series of LSRs. The entry LSR is called “Ingress”, and the exit LSR is called “Egress”. For example, a path consisting of the connected LSR devices 2, 3, 4, and 5 is an LSP. The ingress of the LSP is the LSR device 2, and the egress of the LSP is the LSR device 5.
MPLS may achieve various traffic engineering functions, which may be implemented by other models, with a relative low cost, and may achieve partial automation of the traffic engineering functions. At present, resource Reservation Protocol (RSVP)-Traffic Engineering (TE) is generally employed to support MPLS TE. The RSVP-TE is an extension to traffic engineering based on RSVP. In the RSVP-TE, the messages are mainly classified into two types, i.e., PATH and RESV, which are extensions to the corresponding messages in RSVP. RSVP-TE may provide MPLS TE with configurable explicit path and bandwidth-reservable LSP, and may support the Fast Re-route (FRR), preemption and loop detection of LSP.
In RSVP, an RSVP message has a specialized object called Record_Route Object (RRO) during transmission. The RRO object records the information of the path through which the RSVP message passes. Each time the RSVP message passes through an RSVP node, the RRO carried in the RSVP message is stored into the RSVP node currently passed by the RSVP message (i.e., the local node), and the information of the local node is inserted into the RRO in the form of RRO sub-object, then the updated RRO is carried by the RSVP message to the next hop. The information of the local node includes the address of a message incoming interface of the node, NODE-ID (node identification) of the node, the address of a message outgoing interface of the node, as well of the label and the local protection of the node. In this way, the RSVP message may be aware of the overall situation of the whole LSP when passing through each hop of the LSP. This facilitates the queries of users. In addition, RRO is also used to provide information about path comparison in the FRR of the LSP, and is used by upstream to examine the downstream protection condition.
To implement FRR function over MPLS is to enable network services to be detoured to or switched to a new LSP in the event of a failure on a node or link of an LSP, so as to ensure the network services uninterrupted. To this end, FRR establishes a local protection backup LSP for an LSP, so that the LSP is temporarily replaced by the backup LSP locally when a failure occurs on the local node/link. In the prior art, FRR may establishes two types of backup LSPs, i.e., Next Hop (NHOP) backup LSP and Next Next Hop (NNHOP) backup LSP. An NHOP backup LSP protects a single link of the main LSP between two nodes by a backup link defined between the two nodes. An NNHOP backup LSP protects an intermediate node between two nodes by a backup node defined between the two nodes and by a backup link between the backup node and the two nodes. The method of NNHOP backup LSP is mainly used to protect single node on the main LSP. For example, suppose there are 3 nodes A, B, and C on a main LSP, for the protection of node B, a node D is defined between the node A and node C. The nodes A, D, and C form a backup link, i.e., an NNHOP backup LSP. When a failure occurs on the node B, an RSVP message may bypass the failed node B, and be detoured to the backup link for transmission.
In the prior art, a backup LSP, when established, needs to be bound with the main LSP to be protected so as to establish a protection relationship. When the binding is successful, a “Local protection available” flag is set at an RRO node corresponding to an outgoing interface of a forked node of the protected LSP and the backup LSP, i.e., a Point of Local Repair (PLR). Then a “path” message carries the information of the RRO node to downstream nodes of the PLR. When receiving the “path” message, each downstream node checks whether a “Local protection available” flag at a nearest upstream RRO node is set. If the “Local protection available” flag at the nearest upstream RRO node is set, the downstream node is considered to be a Merge Point (MP) of the main LSP and the backup LSP, and the corresponding LSP state block is set as a protected state. At the MP node, if a failure occurring on the protected LSP is sensed, the corresponding state on the MP is not immediately deleted until the temporarily switching of FRR, so that the LSP is not interrupted.
In actual applications of the above technical solution, when the backup LSP is an NNHOP backup LSP, the MP of the backup LSP can not be identified uniquely in the prior art. Accordingly, the main LSP can not be protected by the NNHOP backup LSP.
The reason mainly lies in that, a downstream RSVP node determines whether the downstream RSVP node is an MP by checking whether the “Local protection available” flag of the nearest upstream RRO node is set. When the backup LSP is an NHOP backup LSP, the nearest upstream RRO node is the RRO node corresponding to the outgoing interface of the PLR. Whether the local node is an MP of the NHOP may be determined uniquely by judging whether the “Local protection available” flag of the nearest upstream RRO node is set. However, if the backup LSP is an NNHOP backup LSP, there is a protected RSVP node between the PLR and the MP, the protected RSVP node may have different number of RRO nodes depending on its manufacturers. In this case, for a downstream node of the PLR, the nearest one or two upstream RRO nodes are not necessarily the nodes corresponding to the outgoing node of the PLR. Thus, whether the local node is an MP of the NNHOP can not be determined by simply checking the “Local protection available” flags of the nearest one or more upstream RRO nodes. Consequently, the state of corresponding LSP state block can not be set. The corresponding backup LSP can not be utilized correctly when a failure occurs on the protected node.